Computer program development, such as development of web based applications, WINDOWS based applications, et cetera, often requires the talents of several specialized individuals. For example, one or more designers (e.g., a visual designer and an interaction designer) may be utilized to provide layout of an application program's user interface in order to provide a visually pleasing, ergonomically designed, intuitive, and/or efficient user interface. The designer may determine where control buttons, list boxes, trees, and other display objects are placed in a program's user interface. A programmer may be utilized to produce the code which will implement the designer's layout as well as the underlying program functionality.
Each of the foregoing program developers brings special talents to the program development process. For example, the designer's education and experience is typically more directed to the arts and less to the sciences, giving this individual unique talents in developing program “eye wash,” although perhaps being limited in programming and complex mathematical skills. The programmer, on the other hand, typically possesses education and experience more directed to the sciences than to the arts, giving this individual unique talents in developing efficient and stable programming code, although perhaps being limited in ability with respect to presenting visually pleasing, ergonomically designed, and/or intuitive user interfaces.
Various development tools have been designed in an attempt to simplify program development, and even to reduce the need for particular specialized talents. For example, graphical development tools, such as FLEX BUILDER available from Macromedia, Inc., have been developed to assist in developing programming code from “drag and drop” object placement within the development environment. Such development tools provide substantial improvement over previous development environments. However, various aspects of program development continue to require specialized talents, or are otherwise less simple to develop various program aspects than may be desirable.
Object sizing and placement when a program user interface window is resized is an example of one program aspect which is often problematic in program development. Directing attention to FIG. 1A, window of a program, such as an electronic mail client, is shown as window 100. Window 100 includes a plurality of panes, shown here as menu bar 110, such as may contain various pull down menus and selectable buttons, box 120, such as may contain various folders (perhaps in a tree structure) and/or selectable list items, and panels 130 and 140, such as may contain various selectable mail object items (e.g., a list of e-mail headers in panel 130 and the contents of a selected e-mail message in panel 140). Window 100 of FIG. 1A is displayed having a particular 2-dimensional size (e.g., 300 pixels wide by 200 pixels tall). The particular size of window 100 in FIG. 1A may be insufficient to display all items associated with the menus, boxes, and/or panels thereof. For example, a number of pull down menu items may not be visible upon menu bar 110 due to its size within window 100 being too small. Similarly, a number of list or tree items associated with box 120 may not be visible and a number of mail items may not be visible within panels 130 and 140 due to their size within window 100. Accordingly, it may be desirable to allow a user to resize window 100 in order to allow desired items associated with the panes thereof to be visible. However, accommodating resizing of windows presents a number of challenges with respect to developing programs that may not be sufficiently addressed without the special talents of individuals involved in the program's development.
FIG. 1B shows window 100 having been resized (e.g., 800 pixels wide by 400 pixels tall). Window 100 of FIG. 1B has been resized in both dimensions, although not equally. It can be seen that the resizing of window 100 from FIG. 1A to FIG. 1B has not affected each of the panes therein equally. For example, although not getting taller, menu 110 has been made wider; although not getting wider, box 120 has been made taller; and panels 130 and 140 have been made both taller and wider. Accordingly, each of the panes may have different behavior, e.g., whether they stretch horizontally or vertically and how they divide space among themselves, in a resizing operation. Describing how each of these items of window 100, even ignoring issues with respect to resizing objects within these items, are to be treated in a resizing operation is complicated for a sophisticated developer and may be beyond the skill level of some designers.
Although it is possible to prohibit the resizing of windows, such as is often done with respect to certain dialog boxes, such a prohibition is typically not an acceptable solution when developing robust applications having a flexible user interface. Accordingly, various techniques have been employed to simplify defining how items within a window are to be treated when the window is resized.
One such technique is to write code, such as a resize handler, to directly address the appearance of panes when a window is resized. For example, panes may be hard coded to add a same number of pixels to their width and/or height as are added to a window during resizing. Such a solution is very code oriented, not very declarative, and not very graphical. Accordingly, certain individuals, such as designers, may not readily adopt such a solution.
Another technique for facilitating resizing of windows has been to define a hierarchy of boxes in which the various items of a window are placed and describing how the various boxes are to be resized. For example, a first level in the hierarchy may be defined to include a first vertical box designated as including menu 110 and a second vertical box designated as including everything else within window 100 (box 120 and panels 130 and 140). The first vertical box may be defined as fixed height, but variable width, thus causing menu 110 grow in width, although remaining fixed in height, as window 100 is resized. The second vertical box may be defined as variable height and width, thus allowing this box to fill the remaining areas of window 100 when resized. A second level in the hierarchy may be defined to include a first horizontal box designated as including box 120 and a second horizontal box designated as including everything else within the second vertical box of the first hierarchical level (panels 130 and 140). The first horizontal box may be defined as fixed width, but variable height, thus causing box 120 to grow in height, although remaining fixed in width, as window 100 is resized. The second horizontal box may be defined as variable height and width, thus allowing this box to fill the remaining areas of window 100 when resized. A third level in the hierarchy may be defined to include a first vertical box designated as including panel 130 and a second vertical box designated as including panel 140. Theses vertical boxes may be defined as variable in height and width, thus causing panels 130 and 140 to grow in height and in width as window 100 is resized. However, in order to determine how these two panels are to be resized within the remaining portions of resized window 100, the vertical boxes of the third hierarchy may be provided with relative sizing information. For example, each of the vertical boxes of the third hierarchical level may be resized to fill 50% of the resized area.
It can be seen that, although providing a simplified technique for defining how items are to be resized, the technique requires an understanding of its hierarchical nature and various relationships between the items within the window. Particular individuals, particularly those which are visually oriented, have difficulty conceptualizing such a hierarchy and typically do not think in relative sizes. Accordingly, the foregoing solution may not present an optimal solution for layout of a user interface by many individuals.